[% setvar title The Perl 6 Summary for the week ending 20030126 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20030126'></a><h1>The Perl 6 Summary for the week ending 20030126</h1>
<p>Welcome to the first Perl 6 summary of the new 'Copious Free Time
enabled' era, which should mean that these summaries will get mailed
out on Monday evening from now on.</p>
<p>We start, as usual, with perl6-internals</p>
<a name='The eval patch'></a><h2>The eval patch</h2>
<p>Leopold T&ouml;tsch continued to work on making <code>eval</code> and its
associated operators work and asked for some opinions about a problem
he was having with jumps between code segments. Jason Gloudon played
sounding board and the two of them found a way forward.</p>
<p><a href='http://groups.google.com/groups?threadm=3E2C816D.4070307@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='The Parrot crashes'></a><h2>The Parrot crashes</h2>
<p>Dan announced that Parrot was crashing big time under (at least) OS X,
throwing segfaults in the NCI mark routine. Other people contributed
reports of what was happening on their platform and Leo T&ouml;tsch
tried to track down the error, working on the assumption that it was
something to do with his eval patch as that was the last patch that
had gone in.</p>
<p>Later in the week Dan realised that part of the problem with OS X was
a problem with <b><i>imclexer.c</i></b>, an autogenerated file being generated
with bad code. Leo reckoned it was a problem with something having
been multiply defined, which had since been fixed.</p>
<p>Still later in the week, Steve Fink offered some analysis on the NCI mark
routine and a patch which attempted to fix the problems he saw with
it. Leo reckoned that the patch wasn't quite right, but the analysis
was good and used that to fix the problem and discovered in the
process that the parrot build process's dependency analysis wasn't
quite up to the mark. (I don't think there's a fix for that yet, but
at least we know the problem exists...)</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f03ba51f9a576c1@' target='_blank'>groups.google.com</a>[192.168.2.1]</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f0aba532561a41c@' target='_blank'>groups.google.com</a>[192.168.2.1]</p>
<p><a href='http://groups.google.com/groups?threadm=20030123040732.GI4862@foxglove.digital-integrity.com' target='_blank'>groups.google.com</a></p>
<a name='Compiling to Parrot'></a><h2>Compiling to Parrot</h2>
<p>K Stol is looking for a final project for his Bachelor's degree and
would like to implement some language targeting Parrot and asked for
suggestions. Simon Wistow suggested PHP or Lua, Leon Brocard suggested
Java (though Gopal V wasn't sure that was such a good idea just
yet). Dan suggested that, just because someone else was already
working on a TCL compiler it didn't mean it wasn't worth trying
anyway, but apparently it would have been unlikely to get approval as
a Bachelor's project. There was some further discussion of Lua and
whether there would be any real point in implementing it and the
thread died down before Mr Stol told anyone what he'd decided to do,
which was rather a shame I thought.</p>
<p><a href='http://groups.google.com/groups?threadm=BAY1-DAV66VOMMxTk0r00015d9e@hotmail.com' target='_blank'>groups.google.com</a></p>
<a name='Extending the packfile format'></a><h2>Extending the packfile format</h2>
<p>Some months ago, J&uuml;rgen B&ouml;mmels offered a patch to extend
the Parrot packfile format whilst retaining backward
compatibility. This week, after a little modification, Leo
T&ouml;tsch applied it. James Mastros wondered if it didn't make
sense (at least before parrot 1.0) to ignore backward compatibility
issues and just make it right. Leo and Dan agreed, but Leo pointed out
that, at least until the switch from assemble.pl to IMCC was complete,
maintaining backward compatibility was the right thing. (So, if you're
currently using assemble.pl to assemble your language, consider moving
it to IMCC sooner rather than later).</p>
<p><a href='http://rt.perl.org/rt2/Ticket/Display.html?id=18056' target='_blank'>rt.perl.org</a></p>
<a name='The long running Objects thread'></a><h2>The long running Objects thread</h2>
<p>Discussions continued.  A good deal of time this week was spent
discussing the overrideablility (there's got to be better word than
that...) of OO method dispatch for different languages (and at a
language level too I hope -- I like flexibility). Python for instance
seems to require that every step in the process be subject to
override. Dan pointed out that dispatch would end up being implemented
as vtable methods on per language Object PMCs so that messages from
one language's objects to another's would use the target language's
dispatch rules. Which seems rather cute (in a good way).</p>
<p><a href='http://groups.google.com/groups?threadm=20030122184654.GA1013@Radii' target='_blank'>groups.google.com</a> -- Christopher Armstrong talks about Python</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f0aba55de36f844@' target='_blank'>groups.google.com</a>[192.168.2.1] -- Dan on how it works.</p>
<a name='Intersegment branching'></a><h2>Intersegment branching</h2>
<p>Leo T&ouml;tsch added a new opcode for intersegment branches, called
<code>branch_cs</code> which was his implementation of the fix that he and Jason
Gloudon had discussed while talking about problems with <code>eval</code>. Dan
didn't think Parrot needed this and that we could just use a plain
jump. Leo pointed out that there were several places where this didn't
quite work, especially in the presence of JIT optimization. Dan didn't
think that didn't mean it wouldn't work, but reckoned that the cases
Leo pointed out were reasons he wanted to see intersegment jumps
mediated by subroutine calls. Leo followed up to this with an
example. I can't for the life of me tell if this was a counter
example, a suggestion or what though.</p>
<p>This reemerged as a new thread with the subject 'Transferring control
between code segments'. Dan opened the thread by discussing the design
perspective and laying down a few edicts. He went on to discuss the
issues that Leo's 'phenomenally cool' <code>compile</code> opcode has exposed in
his earlier handwaving and replaced the handwaves with more detail.</p>
<p>People were generally happy to see this, but there were a few small
issues with it which weren't explicitly resolved this week.</p>
<p><a href='http://groups.google.com/groups?threadm=3E2EBE60.6070304@toetsch.at' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=a05200f02ba5497181516@' target='_blank'>groups.google.com</a>[192.168.2.1] -- Design issues</p>
<a name='Bytecode Metadata'></a><h2>Bytecode Metadata</h2>
<p>Dan responded to the earlier discussion of extending the packfile
format by opening a discussion of the type of metadata that might be
useful to have in either the on disk packfile or in memory
bytecode. He reminded everyone that parrot may have to ignore (or at
least mistrust) the metadata and opened the floor suggestions.</p>
<p>James Michael DuPont came up with a proposal involving RDF which Dan
thought might well be overkill (albeit interesting overkill) since he
had been thinking more about metadata that would be used by the engine
itself or provided to programs running on it.</p>
<p>Various other suggestions were made, and it's apparent that one
immutable design guideline is that any bytecode format for Parrot
must allow for executable code to be mmapped in.</p>
<p>Leo T&ouml;tsch has a patch implementing a simplified API for
generating packfiles and wondered if he should check it in.</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f01ba5492b60e51@' target='_blank'>groups.google.com</a>[192.168.2.1] -- Opening remarks</p>
<p><a href='http://groups.google.com/groups?threadm=20030123062939.54929.qmail@web41505.mail.yahoo.com' target='_blank'>groups.google.com</a> -- The RDF
bazooka</p>
<a name='Odd JIT timings'></a><h2>Odd JIT timings</h2>
<p>Dan reported that <b><i>examples/assembly/mops_p.pasm</i></b> was running slower
with JIT optimization than without under OSX, which doesn't seem
right. Daniel Grunblatt pointed out that JIT cores that don't optimize
many opcodes will always be slower than a Computed Goto (CG) core and
there aren't many optimized opcodes for the PPC architecture. Bruce
Gray pointed Dan at an introduction to PPC assembler in case Dan
wanted to add to the score of optimizations. Anyone else is interested
could take a look too, kudos awaits the heroic implementer.</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f05ba569ca7a572@' target='_blank'>groups.google.com</a>[192.168.2.1]</p>
<p><a href='http://www-106.ibm.com/developerworks/linux/library/l-ppc/' target='_blank'>www-106.ibm.com</a></p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<p>There was a little more diversity of discussion this instead of
concentration on a single massive thread, though that thread did, of
course, continue on its path.</p>
<a name='L2R/R2L syntax'></a><h2>L2R/R2L syntax</h2>
<p>There was some discussion of implementing conditionals (<code>if</code>, <code>else</code>
etc) as functions rather than special keywords. Personally I'm not
sure that anything that monkeys with Perl's normal order of evaluation
can strictly be called a function, but what the hey.</p>
<p>Buddha Buck showed off a rather neat implementation of if, then and
else which borrowed some of its implementation from a Smalltalk
like 'Bool' class with <code>isTrue</code> and <code>isFalse</code> methods and then used
multiple dispatch to get the rest.</p>
<p>In another subthread, Michael Lazzaro explained why he still wanted
Right to Left pipelining, even though he was much more at ease with
Perl 6's rules for when you needed a comma in an argument list. It
appears to be mostly about teachability.</p>
<p>Damian popped up to make (at least) Graham Barr and me happy when he
said that he didn't think the Perl 5ish functional forms of <code>map</code> and
<code>grep</code> etc would be going away. Huzzah!</p>
<p><a href='http://groups.google.com/groups?threadm=3E2C3BBB.3070308@14850.com' target='_blank'>groups.google.com</a> -- Buddha's Smalltalk port of
conditionals</p>
<p><a href='http://groups.google.com/groups?threadm=00A74788-2CD8-11D7-B567-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- Michael
Lazzaro on grep, map and explicit pipelines</p>
<p><a href='http://groups.google.com/groups?threadm=3E3337E4.1070800@conway.org' target='_blank'>groups.google.com</a> -- map/grep/etc still functions</p>
<a name='A proposal on if and else'></a><h2>A proposal on if and else</h2>
<p>Brent Dax proposed a solution to the problem of implementing <code>if</code> and
<code>else</code> as functions (the problem being that, unless you cuddle all
your <code>else</code>s, perl will intuit a semicolon at the end of <code>if</code>'s
block and things will get confused) by proposing that <i>all</i> code
blocks take an optional 'else', accessed by the <code>$code.else</code>
attribute, one of the side effects of which would be that <code>elsif</code>
would become <code>else if</code>.</p>
<p>Austin Hastings wondered if supporting 'separable verbs' might be a
better way forward. The idea certainly looks interesting, the best
summary of the idea I can give you is to point you at Austin's
original message though.</p>
<p><a href='http://groups.google.com/groups?threadm=004201c2c0b8$2bfab000$7b01a8c0@deepblue' target='_blank'>groups.google.com</a> -- All blocks are elseable</p>
<p><a href='http://groups.google.com/groups?threadm=20030120222955.33503.qmail@web12305.mail.yahoo.com' target='_blank'>groups.google.com</a> -- Separable verbs</p>
<a name='Arc: An Unfinished Dialect of Lisp'></a><h2>Arc: An Unfinished Dialect of Lisp</h2>
<p>Rich Morin pointed everyone at Paul Graham's presentation at the first
Little Languages conference about Arc, pointing out that Graham had
some interesting things to say about language design. The discussion
that followed was mostly off topic (in the sense that they weren't
talking at all about Perl 6). Graham's paper is interesting though.</p>
<p><a href='http://groups.google.com/groups?threadm=p05200f28ba536351462d@' target='_blank'>groups.google.com</a>[192.168.254.205]</p>
<p><a href='http://paulgraham.com/arcll1.html' target='_blank'>paulgraham.com</a></p>
<a name='Array/Colon question'></a><h2>Array/Colon question</h2>
<p>Michael Lazzaro wondered about the seemingly different meanings of
colon in:</p>
<pre>    print $FH : $a;    # $FH is an indirect object
    @a = 0 .. 10 : 2;  # @a is (0,2,4,6,8,10)</pre>
<p>and wanted to know when <code>:</code> meant 'step' and when it designated an
indirect object. Brent Dax helped clear things up. Essentially <code>:</code> is
a 'supercomma' and different operators and functions interpret what
comes after the supercomma in different ways. <code>..</code> treats it as
specifying a step.</p>
<p><a href='http://groups.google.com/groups?threadm=66FE52DB-2EFE-11D7-BD12-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Multiple Dispatch by Context?'></a><h2>Multiple Dispatch by Context?</h2>
<p>Piers Cawley wondered if it would be possible to specify a multimethod
by context as well as by parameter types. Dan Sugalski managed to hole
the proposal below the waterline with a neat set of multidispatch
declarations that led to a horrible ambiguity. Thomas A Boyer pointed
out that Ada can handle such ambiguities but that it was a complete
pain to implement and voted against using return type for multiple
dispatch.</p>
<p><a href='http://groups.google.com/groups?threadm=m27kcvqa1z.fsf@TiBook.bofh.org.uk' target='_blank'>groups.google.com</a></p>
<a name='Who's Who in Perl 6'></a><h1>Who's Who in Perl 6</h1>
<p>Ah... um... I appear to be lacking an answer set this week.</p>
<a name='Announcements, Acknowledgements and Apologies'></a><h1>Announcements, Acknowledgements and Apologies</h1>
<p>I'm afraid to have to announce that, as of this week I can no longer
donate the fee for these summaries to the Perl Foundation it's
currently my only source of income. On the positive side, now that I
don't have to spend 8 hours a day working for someone else I should be
able to get the Summary mailed out to the Perl 6 lists on a Monday
from now on.</p>
<p>Thanks to everyone who sent me mail about my redundancy. No matter how
good it feels not to have to get up at 5.50 every morning with the
prospect of not getting home again 'til at least 18.40 it's still a
terrible shock to lose your job. Thankfully we look to be in a much
better position this year than we were last time I was out of work;
I'm hoping that, if I can get a few more freelance writing gigs and
maybe a little consultancy I'm not going to have to go back to the 4
hour commutes for the foreseeable future.</p>
<p>Thanks too to everyone who's given me answers for the Who's Who
section since this summary started. I'm sorry to be retiring it for
now, but as new blood filters into the Perl 6 community I hope I'll be
able to restart it some time further down the road.</p>
<p>If you appreciated this summary, please consider one or more of the
following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, job offers or concrete proof either way about Iraq's weaponry to p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a>'></a>Send feedback, flames, money, job offers or concrete proof either way
about Iraq's weaponry to <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i></li>
</ul>
</div>
